Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Find/Replace overlay: fix Ctrl+F6 crash on Linux #1975

Merged

Conversation

Wittmaxi
Copy link

Avoid being stuck in an event loop by reacting asynchronously to part activation events.
Additionally, manually give focus to the editor part after switching. This behavior is default on windows but not consistent on Linux.

how to test

after pressing Ctrl+F in a few different Editors,
(on Ubuntu), press Ctrl+6 repeatedly to switch between Editor parts. We (quite obviously) don't expect anything to crash!

fixes #1951

@Wittmaxi
Copy link
Author

@iloveeclipse can you please confirm that this fixes your issue on Linux?

Copy link
Member

@iloveeclipse iloveeclipse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR fixes the problem on Linux, thanks. Some smaller issues see in comments above.

}

getShell().setVisible(isPartCurrentlyDisplayedInPartSash());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code called from asyncExec() without checking whether preconditions are still met : the targetPart is still opened and it's shell is non null.

Same for the code below in the asyncExec() call.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can add checks for whether the shell is still open, sure. How do I check whether the targetPart is still open? I didn't find a method for that

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

targetPart.getSite().getPart() would be null.

Copy link
Contributor

github-actions bot commented Jun 17, 2024

Test Results

 1 210 files  ±0   1 210 suites  ±0   1h 3m 33s ⏱️ + 3m 14s
 7 663 tests ±0   7 431 ✅  - 1  231 💤 ±0  1 ❌ +1 
16 100 runs  ±0  15 586 ✅  - 1  513 💤 ±0  1 ❌ +1 

For more details on these failures, see this check.

Results for commit 4289711. ± Comparison against base commit d67d6c7.

♻️ This comment has been updated with latest results.

@Wittmaxi Wittmaxi force-pushed the task_4-find/replace_overlay-fi branch 2 times, most recently from b85fd61 to a5a9122 Compare June 17, 2024 12:46
@Wittmaxi
Copy link
Author

I am not sure if my PR is failing but it looks like it isn't?

grafik

@fedejeanne

}

@Override
public void partDeactivated(IWorkbenchPart part) {
// Do nothing
Display.getDefault().asyncExec(this::adaptToPartActivationChange);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

better to use getShell().getDisplay().asyncExec - here and below

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ad63e43

NOTE: getShell() is not the "Eclipse Shell" but rather the shell of the Dialog.
Since this asynchronous execution is very quick, it's likely not a problem (?)

@@ -262,6 +258,32 @@ public void partClosed(IWorkbenchPart part) {
public void partOpened(IWorkbenchPart part) {
// Do nothing
}

private void adaptToPartActivationChange() {
if (getShell() == null || targetPart.getSite().getShell() == null) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

targetPart.getSite().getShell() == null that is same as getShell(). Instead, check for the targetPart.getSite().getPart() == null

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, that is not the same as getShell() as this code is ran from inside of a Dialog. getShell() returns the shell of the Dialog, and targetPart.getSite().getShell() returns the the shell which contains the part we are targetting.

Sure, I can change the check for whether the part is null. Please refer to my comment down-below.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pleas ehcekc whether my change in ad63e43 is addressing your concerns

}

private void focusTargetWidget() {
if (targetPart.getSite().getShell() == null) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

targetPart.getSite().getShell() == null should be replaced with getShell() == null || targetPart.getSite().getPart() == null

Copy link
Author

@Wittmaxi Wittmaxi Jun 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't quite understand why that makes sense, but if it is true that targetPart.getSite().getPart() != null implies targetPart.getSite().getShell() != null, then that should work by contraposition.

Please keep in mind that this code is ran from inside a Dialog, so getShell() does not return the same shell as the shell the part is located in.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I performed the changes in ad63e43

@fedejeanne
Copy link
Contributor

I am not sure if my PR is failing but it looks like it isn't?

grafik

@fedejeanne

LGTM now :-)

Once Andrey's remarks have been addressed, this PR can be merged-

@Wittmaxi Wittmaxi force-pushed the task_4-find/replace_overlay-fi branch 2 times, most recently from 1f97f91 to ad63e43 Compare June 22, 2024 10:14
@Wittmaxi Wittmaxi requested a review from iloveeclipse June 24, 2024 06:58
@HeikoKlare
Copy link
Contributor

@iloveeclipse have your concerns been addressed (in particular #1975 (comment)), so that we may merge this PR?

@iloveeclipse
Copy link
Member

I haven't checked the PR since, but please rebase before merge, so we see test results with latest master state.

@HeikoKlare HeikoKlare force-pushed the task_4-find/replace_overlay-fi branch from ad63e43 to 09865c8 Compare June 27, 2024 15:58
@HeikoKlare
Copy link
Contributor

but please rebase before merge, so we see test results with latest master state.

Sure, I have just rebased it to get some recent test results but depending on when this PR will be marked as ready to be merged, we will rebase again.

@Wittmaxi Wittmaxi force-pushed the task_4-find/replace_overlay-fi branch from 09865c8 to 126ba0d Compare July 1, 2024 06:22
@Wittmaxi
Copy link
Author

Wittmaxi commented Jul 1, 2024

@HeikoKlare @akurtakov I have merged this PR with the latest master

Copy link
Member

@iloveeclipse iloveeclipse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@iloveeclipse
Copy link
Member

@Wittmaxi : thanks, I've finally had time to test the patch, it fixes the problem. Please manually rebase on master, as due the package move the change can't be merged.

@Wittmaxi
Copy link
Author

Wittmaxi commented Jul 2, 2024

@HeikoKlare I won't get to merge these changes until next monday. If you have some spare time and if it's straight-forward to do, could you please merge them to master?

@HeikoKlare HeikoKlare force-pushed the task_4-find/replace_overlay-fi branch from 126ba0d to 23d62ec Compare July 3, 2024 16:06
@HeikoKlare
Copy link
Contributor

HeikoKlare commented Jul 3, 2024

I've rebased the changes on master. The local Git client is able to automatically consider the file relocation when performing a rebase, so rebase was performed without manual effort and thus without the risk of unintended changes/mistakes. Once the GitHub checks have finished successfully, we can merge this.

Edit: I had to apply a slight change concerning the way the source viewer is accessed (https://github.com/eclipse-platform/eclipse.platform.ui/compare/23d62ec2c50dc399b7049afdebe22922b7dcf70d..6e143ebff2b1705d52e9f4e1984e7faadcf71175), exactly like applied at other places when moving the find/replace classes in a separate package (#2013).

@HeikoKlare HeikoKlare force-pushed the task_4-find/replace_overlay-fi branch from 23d62ec to 6e143eb Compare July 3, 2024 16:20
Avoid being stuck in an event loop by reacting asynchronously to part
activation events.
Additionally, manually give focus to the editor part after switching.
This behavior is default on windows but not consistent on Linux.

fixes eclipse-platform#1951
@HeikoKlare HeikoKlare force-pushed the task_4-find/replace_overlay-fi branch from 6e143eb to 4289711 Compare July 3, 2024 17:09
@HeikoKlare
Copy link
Contributor

I've tested the change on Linux, Windows and MacOS. I can also confirm that it fixes the reported bug on Linux and also works as expected on Windows and MacOS.

@HeikoKlare HeikoKlare merged commit f8acd2d into eclipse-platform:master Jul 4, 2024
15 of 16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

find/replace overlay: makes Eclipse unusable on switching editors
4 participants